Ack!!!

I got hit with a surprise fsck tonight. Uploading 2.4GB of new music and a rather large audiobook, and it chooses now to do a disk check. And the partitions were not dirty. Ah well, I knew I was coming close to the number of mounts. Time to leave the player to sync overnight... Dual 80s will take (from experience) about 1.5 -> 2 hours.

I am just glad I didn't try this at the office!

You just had to have all that space... didn't you!

And with similarly stunning timing, mine crashed as I was synching (my own fault), and now Emplode has been checking disk integrity for half an hour... and I really ought to get to sleep.

Serves me right for uploading a few albums just before going to bed, then messing around with my network settings as the synch was happening.

Yes, yes, I know I was being stupid, but I just wanted to check something, then noticed something else I'd been meaning to change, so changed it, then thought "Oh bugger, I'm still uploading". Mea culpa.

Update:

I loaded a bunch of new tracks, and I got put through another FSCK cycle. Now, I know for a fact that I did not do anything that would have left the filesystems dirty. This is on my primary player, and it does not get moved much.

So, I am wondering if the disk check from the latest build is not clearing the dirty flags properly. Immediately after the check completes, I will go and look at the partitions. If what I suspect is true, something will still be marked as dirty or expired.

Note, I have hijack 334 and 2.0 developer on the player, but I have not disabled the fsck timing check through hijack.

Might it be failing due to lack of memory like on Laura's due to your big disks?

I don't think so. The syncronization completes without any errors. I went into the player after the sync, and there was no sign of problems, the new files were there, etc. It looks completely clean.

I am performing a manual fsck now, just in case. Maybe I did do something stupid last night, and didn't realize it. It was a rough day, and I may have missed something.

Aha!

You are right. Even though the drives were clean, I did an fsck from command line and received the following:

empeg:/empeg/bin# fsck -fay /drive0
Parallelizing fsck version 1.19 (13-Jul-2000)
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
ext2fs_check_if_mount: No such file or directory while determining whether /dev/
hda4 is mounted.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
no room for private writable mapping
error: -12
fsck.ext2: Memory allocation failed while retrying to read bitmaps for /dev/hda4
empeg:/empeg/bin#

I would have expected a failed fsck to cause emplode to fail, but perhaps not. So I turned on swap, and will go from there.

Now, my question is: does emplode turn on swap when it attempts to fsck drives? If not, then other people with 80GB drives will start seeing this problem more frequently.

Paul,

Have you thought of installing jfs/ext3 on your empeg's? I've been using hijack compiled with ext3 and fsck is a thing of the past.

Greetings!

I have been tempted, but I wanted to keep to a more standard install. As I experiment with different / new drive configurations, I like to try and find what breaks and why. This is one instance.

does emplode turn on swap when it attempts to fsck drives?

IIRC, it does. But the player's still running, which might just push you over the edge, memory wise (even including the swap).